Subject: re:PU Names in SNANAU MIB

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 29 Nov 1995 09:10:00 -0500

In message "PU Names in SNANAU MIB", [email-masked]' writes:

>In the release 14 of the Formats and Protocols Manual (the latest -
>I think??), IBM has actually documented the presence of the 0x0E 
>Network Name CV in both the ACTPU and ACTLU. However, I have yet 
>to see one flow in a sniffer trace - and we are running VTAM 4.3 
>(the latest) and talking to OS/2 CM, which is supposedly the most 
>pure form of SNA protocol stack implementation.

As mentioned elsewhere the NCP boundary function, and the boundary function
in DLUR both appear to remove this useful information from the ACTPU and
ACTLU just in case some illiterate PU2.0 implementor has chosen to impose a
length check on these requests.  You will see the vectors on a VTAM IO or
Buffer trace of the SSCP-PU and SSCP-LU sessions.

>Re:  Jim Fletcher's email on the uniqueness of PU names...
>
>> Just to clarify, PU names are "locally" significant to a given VTAM. I can
>> have the same PU name defined in every VTAM, representing a totally
>> different PU. So in order to uniquely qualify the PU name, one must qualify
>> it with its current owning VTAM. LU names are global, so they must be
>> unique when network qualified within the universe.
>
>This needs further clarification. Are you saying that some 
>"fully-qualified" names are unique within a given network (e.g. 
>a given "net ID") whereas other FQ names are not??? Possibly my
>confusion arises in the distinction between "PU names" and "CP Names"???

Even though the "PU name" appears to be the name of the PUCP NAU in the PU
2, there are no information exchanges (aside from the hierarchy name vector
in a network management request) which will ever carry this name outside of
a domain.  The "PU name" actually appears architecturally to be the adjacent
link station (ALS) name, and its use to also refer to the PUCP NAU (which
has the same network address in the attaching subarea) is an
implementation decision.
>
>I thought a typical reaction to an unidentified CV would be to throw 
>it away? The name information in an ACTPU/ACTLU would definitely be
>of use! Has IBM ever considered making the inclusion of the 0E CV an
>optional configuration parameter in a VTAMLST? Another question: How did 
>this end up in the Formats Manual if it is not supported? [Note: actually, 
>I've been working with SNA long enough that I think I know the answer to 
>this one ;-) ]

The vectors were added to the -14 level of SNA Formats because they are now
carried in ACTPUs and ACTLUs which are encapsulated inside the SSCP
transport GDS variable on the DLUS-DLUR pipe.  However DLUR copies the NCP
boundary function in deleting them before sending them to an externally
attached PU 2.0.  They are available to an internal PU 2.0.  It appears that
the vectors are never sent on a data link.  I have read through SC30-3112,
which is the only formal architectural documentation for a PU 2.0, and I
cannot find any statement that anything in the ACTLU or ACTPU is to be
looked at beyond the fields documented in the pre -14 level of SNA Formats.
However there do appear to be a number of implementors in the past who have
demonstrated that they do not bother to read specifications.  Moreover there
is no way that we can absolutely guarantee that noone has EVER delivered
an implementation of a PU 2.0 which rejected an ACTPU or an ACTLU with the
additional flags and the CVs included.  Bummer!  However if you look at the
ACTPU and ACTLU you WILL observe that they already include a number of flags
and field values which clearly did not exist in 1973.  Somehow IBM felt the
courage to make those changes.  In particular IBM added the PU Capabilities
vector (X'80') to the ACTPU (somewhere between -10 of SNA Formats and -12)
without worrying that THAT might upset some brand-X PU 2.0.  It is a little
difficult to imagine someone building an implementation which would
tolerate one vector, and not another, especially since if they had kept a
copy of the -6 level of SNA Formats they would have seen three more control
vectors (X'09', X'0B', and X'18'), and if they had a VTAM license and
obtained a copy of LY43-0081 they would have seen the X'0E' vectors as well.

IBM didn't care what we third party implementors did 5 years ago when they
last changed the ACTPU.  Is it reasonable to be denied access to this
extremely useful information merely because IBM is NOW being considerate of
third party manufacturers who MAY HAVE screwed up in their PU 2.0
implementations?

WHEREAS:  Any PU 2.0 implementation which fails to accept an ACTPU with the
	network name control vector deserves to lose market share, and the
	information contained in this vector is crucial to network
	management integration.
MOVED:  That the SNA Architecture or Record be amended to explicitly require
	that PU 2.0 nodes ignore unrecognized control vectors on ACTPU and
	ACTLU.  Further that the DLUR specification be amended to remove the
	boundary function feature which deletes the network name control
	vector from ACTPU and ACTLU.  Further IBM is requested to modify the
	NCP boundary function, which lies outside the purview of the AIW, so
	that it also retains these control vectors.

NOTE: This file was encoded using QUOTED-PRINTABLE for safe
transmission. Any binary data and/or lines longer than 132 characters in the original
attachment was encoded.
Received: from hubbub.cisco.com by bnr.ca id <[email-masked]>; T=
ue, 28 Nov 1995 14:23:27 -0500
Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by hubbub.cisco.c=
om (8.6.12/CISCO.GATE.1.1) with SMTP id LAA19251 for <[email-masked]=
>; Tue, 28 Nov 1995 11:19:58 -0800
X400-Received:  =

 by mta bnr.ca in /PRMD=3DBNR/ADMD=3DTELECOM.CANADA/C=3DCA/; Relayed; Tue=
, 28 Nov 1995 14:19:07 -0500 =

X400-Received:  =

 by /PRMD=3DBNR/ADMD=3DTELECOM.CANADA/C=3DCA/; Relayed; Tue, 28 Nov 1995 =
14:18:30 -0500 =

X400-Received:  =

 by /PRMD=3DBNR/ADMD=3DTELECOM.CANADA/C=3DCA/; Relayed; Tue, 28 Nov 1995 =
13:24:00 -0500 =

Date:  Tue, 28 Nov 1995 13:24:00 -0500 =

X400-Originator:  /dd.id=3D1582804/g=3Djim/i=3Dj/s=3Dcobban/@bnr.ca =

X400-MTS-Identifier:  =

 [/PRMD=3DBNR/ADMD=3DTELECOM.CANADA/C=3DCA/;bcars735.b.777:28.10.95.19.18=
=2E30] =

X400-Content-Type:  P2-1984 (2) =

Content-Identifier:  re:PU Names i... =

From
: "jim (j.) cobban" <[email-masked]>
Sender: "jim (j.) cobban" <[email-masked]>
Message-ID:  <"8785 Tue Nov 28 14:18:33 1995"@bnr.ca> =

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject:  re:PU Names in SNANAU MIB =

=00=00=00=